So it’s a few days after Christmas, and like most of us tech-heads, I’ve got a few more gadgets to play with. First up: the Creative Zen 4GB. This one was a little bit of a saga. Last year, we got the kids no-name MP3 players, on the theory that we didn’t want to spend megabucks on something they wouldn’t use. They made valiant attempts to use them, but the little machines just weren’t up to the job. So, it seemed prudent to buy them iPods this year. Well, except for Apple’s attempts to break all non-iTunes iPod software, which had the side effect of making the devices unusable under Linux. Still, this was what they wanted, and they had been good this year, and very patient with my ever-more-convoluted schemes to get the old players working. So, iPod Nano 3Gs for both of them. My heart sank as I watched some of my hard-earned money go to reward such behavior. As part of the deal, I vowed to find a non-Apple player that would be good for when the iPods gave up the ghost or became “uncool”. And my dear wife, upon hearing this, went online, did some research, and bought me the aforementioned Creative Zen 4GB. From a Linux perspective, it’s in the “not quite ready for prime time” mode. Rhythmbox and Banshee are working on support; I tried a prerelease of Rhythmbox, and found its support to be very unstable. The only usable app is Gnomad2, which has a terrible UI and also occasionally crashes, but can manage to upload audio, video, and photos without too much hassle. Still, this is a problem of fine-tuning, and not of a hostile hardware vendor; I’m confident that these devices will be well-supported in the near future. The Zen is picky about what video files it will play, but I managed to figure it out: DivX or XviD video, 320×200 or smaller image size, encoded at a 480 kbit/sec video bitrate or less. Other video files might work, too, but you’ll have to find them on your own. My Zen has a little problem with the button locking feature: after unlocking, the screen comes up to all-white, and you have to power-cycle it to get the display back. I’m assuming this is a firmware bug, as the screen is still visible for a short time after engaging the lock. Other than this, the Zen is a delight, and every bit as functional as the iPod. The other nice gadget: a 24-inch LCD from Envision, bought after Christmas with a combination of gift cards, exchanges, and some of my own money. It was an open-box, and I saved about $80 for that; the only problem turns out to be a single dead pixel in the corner of the screen which is barely visible. It does 1920×1200 in very nice, bright color. Here, too, an improvement on my life only came after some effort. Debian 4.0’s drivers for the Intel graphics chipset are not capable of driving a widescreen LCD; the best I could get was 1600×1200, a normal-width resolution stretched across the wide display. I booted an Ubuntu Gutsy live CD to verify that the problem wasn’t with the monitor, and then set to the task of backporting everything I needed from lenny. Happily, before I started, I found that someone (Holger Levsen, to be exact) had done the work for me. Things are now about 90% there. The new drivers still don’t have everything figured out for running both Compiz desktop effects and XVideo acceleration at the same time, so I’ve had to turn XVideo off. My computer can render video without hardware support, but the quality isn’t as high. But, I have my nice wide screen, with crisp fonts and lots of room. I figure I’ll live with what I have until lenny releases, and then see what progress has been made.

I’m very surprised about the popularity of an old post of mine, regarding my experiences with CompUSA. It continues to collect horror story comments, the last one coming less than three weeks ago. While any company has its detractors (especially any company dealing directly with the public), it seems odd to me that people continue to be motivated enough to post to my blog, of all places, their tales of woe. For me, life has been very CompUSA-less of late. Indianapolis now has a Fry’s, one of only two east of the Mississippi as of this writing, and for someone in the relatively tech-starved Midwest, it is a godsend. (People from the west coast: please stifle your laughter as best you can.) And evidently enough of these horror stories have been passed around that they felt the need to close over half their stores in February. The Indy store was spared that time, but not for long.

The electronics retailer decided to finish what it had started earlier this year, announcing that it would sell or close the remainder of its stores in the US after the holiday season. The company, controlled by Mexican retail management company Grupo Sanborns since 1999, has been sold to Gordon Brothers Group, a restructuring firm that will be responsible for selling off the remainder of its assets.

In an abstract sense, less competition in the electronic retail business isn’t ever good. But it’s arguable that we’ve never had so much competition in the electronic retail business if you count the Internet stores that have sprung up all over. And I’m certainly happy to see an outfit that will slander people for profit go belly-up.

Carver County, Minnesota, is in big trouble. (via buzz.mn)

Eric Mattson was not surprised that the small vacant lot he bought last year near the shores of Lake Waconia was increasing in value. What shocked him was the $189 million market value the Carver County assessor’s office came up with for the 55- by 80-foot lot, making it the most valuable property in Waconia and possibly the county.

Of the resulting $2.5 million tax windfall, about $900,000 had already been spent by the time Mattson got the bill and came in to complain. They’re now looking at spending cuts and new taxes to pay for the shortfall.

“This is not an ‘oops.’ This is a major error that affects an awful lot of people,” said Mark Lundgren, director of the Carver County division that oversees the assessor’s office.

So how could someone make such an egregious error?

Lundgren said the trouble began in August when a clerk went into Mattson’s file to change the designation of the property, at 233 Lake St. E., from homestead to non-homestead to reflect its change in status after its sale.

The clerk filled in the $18,900 proposed valuation, but then mistakenly hit the key to exit the program. The computer added four zeros to fill out the nine numerical spaces required by the software, thus indicating the value was $189,000,000.

So many thing come to mind, most of which are probably too snarky. But a few observations come to mind:

• Don’t just pin this on the clerk. The major mistake was with the programmers, whose software did such an unexpected thing, and on the auditors, who missed a $2.5 million mistake. (Oddly, given that audit failure was an issue, the only solution worth mentioning in the article was “more auditing”.)
• Programmers, cherish your input. Do not auto-munge it without at least user review! And, I’d argue, don’t auto-munge it at all if the result is at all valuable. Validate it, sure, but don’t change it; force the user to fix his or her own mistakes. After all, if your program was so smart as to know what the user “meant”, why does it need manual data entry at all?
• Use modern tools! What kind of data store today requires zero-padding? MySQL is a free download, and very popular; for all its perceived faults, it can at least store numbers of variable sizes correctly.

Today, we released the first beta of LSB 3.2. If all goes well, this will hopefully be the only beta. We’ve been working on 3.2 for a while, and we’re really excited about it. We’ve added quite a few interfaces, based on feedback from application vendors and others. There are whole new sections: printing support, Perl and Python, FreeType, Qt 4, and trial use support (our new name for “optional”) for Xrender, Xft, and the ALSA API. Betas can only be as good as the people participating; more feedback means a better standard. So please go check out the beta. Look at the whole thing, or just parts you’re interested in. Read the spec, or check out the tests, or try building your favorite open-source app with our SDK. We’re hoping for a release before Christmas, but that depends on the feedback we get, of course. And we’d rather know about that really big issue we forgot about and delay the beta than find out after the release. So get cracking!

Wow. Has it really been that long since my last post? It occurred to me today, as I upgraded to the latest WordPress and watched the ongoing security nightmares, that going through this effort is only useful if I actually use the darned thing. And I’ve been busy; yes I have. I’m now the webmaster for my son’s Boy Scout troop, using MediaWiki as a CMS with an eye to encouraging more parent and Scout participation in the site. I’ve been to Montreal and Salt Lake City, among other places. And I’m preparing to upload a Debian package for virtualenv, a cool alternative to OS virtualization in the Python space. More later.

I was a little surprised to see a message of thanks for me and my old Progeny colleagues. Unfortunately, the news at Progeny’s home page was not good:

We are sorry to inform you that Progeny Linux Systems, Inc. ceased operations April 30, 2007.

It’s always a little sad to see a former employer go away, even when you feel the company brought its troubles onto itself. Imagine how much worse it is to see something die that you thought had a lot of potential, with fabulous co-workers, above-average management, and really good ideas. It’s often been said that competence and vision are not sufficient for success; without getting into the details, Progeny is now Exhibit A in making that case for me. I am grateful for having worked there, and am proud of what we accomplished. It wasn’t easy surviving the dot-com bust and building a new business model for ourselves. And it’s certain that I wouldn’t be where I am today without the opportunities Progeny gave me. I wish my former colleagues well as they find new jobs. Nearly everyone who passed through Progeny was top-notch, and would make excellent hires.

The old testing release is now Debian 4.0:

The Debian Project is pleased to announce the official release of Debian GNU/Linux version 4.0, codenamed etch, after 21 months of constant development. Debian GNU/Linux is a free operating system which supports a total of eleven processor architectures and includes the KDE, GNOME and Xfce desktop environments. It also features cryptographic software and compatibility with the FHS v2.3 and software developed for version 3.1 of the LSB.

That last bit needs to be proven, which I’ll be doing this week.

From a Fluendo employee:

Are we evil that we don t take more hours out of our day to build on glibc 2.3 ? You bet, we are cold heartless bastards. But in reality 90% of the people on glibc 2.3 are users that have an upgrade path to a more recent version of their distro; the other people are future Debian Etch users. I m sure the Etch releasers have convinced themselves of the usefulness of not releasing with a glibc 2.4 that is more than 15 months old, and instead opt for an even older series, even before they actually release. But I am starting to wonder more and more who the people are that are waiting for a release like this.
Realistically speaking, it is possible that we may add glibc 2.3 plugins in the future if we see that more than just Debian is affected. We are not against taking your money for giving you a service that works. But the hours in our day are just as scarce as they are in yours. I just wanted to explain this to people that want to know, to take away your incentive to complain about a nameless faceless Company being Evil to you.

Elsewhere, we learn why Debian is so “backward”. In sum: upgrades from the current stable would break with 2.4, and not all Debian architectures are supported well by 2.4. I suspect the market for Linux multimedia plugins isn’t a huge one, and Debian is still popular both for end users and as the basis for other efforts. Given that, doesn’t it make sense not to artificially exclude a whole chunk of your potential market? Of course, I think I know of someone who could help here…

I saw my first Sun workstation about 15 years ago, in 1992. I was a business student at Purdue University, and a childhood love for computers had just been reawakened. I was spending countless hours in the basement of the Math building, basking in the green phosphorescent glow of a Z29 and happily exploring every nook and cranny of the Sequent Symmetry upstairs. It didn’t take too long to discover, though, just a short walk away in the computer science building, several labs full of Sun workstations. Suddenly, the Z29 didn’t have quite the same allure. A few months later, I walked over to the registrar’s office and changed my major to computer science. (OK, advanced tax accounting had something to do with it too.) Everything I know about computing I learned on those Sun workstations, as did so many other early Linux developers; I even had my own for a while, after I joined the University of Arizona computer science department in 1997. But within a year, the Suns were starting to disappear, replaced by Pentiums running Red Hat Linux. More and more people coming through university computer science programs were cutting their teeth on Linux, much as I had on Sun. Pretty soon, Sun was increasingly seen by this new generation as the vendor who didn’t “get it”, and Sun’s rivals did a masterful job running with that and painting the company literally built on open standards as “closed”. To those of us who knew better, it was a sad thing to watch. The last several years have been hard for Sun, but the corner has been turned. As an outsider, I’ve watched as Sun has successfully embraced x86, pioneered energy efficiency as an essential computing feature, open sourced its software portfolio to maximize the network effects, championed transparency in corporate communications, and so many other great things. Now, I’m going to be a part of it. And, so, I’m excited to announce that, as of today, I’m joining Sun to head up operating system platform strategy. I’m not saying much about what I’ll be doing yet, but you can probably guess from my background and earlier writings that I’ll be advocating that Solaris needs to close the usability gap with Linux to be competitive; that while as I believe Solaris needs to change in some ways, I also believe deeply in the importance of backward compatibility; and that even with Solaris front and center, I’m pretty strongly of the opinion that Linux needs to play a clearer role in the platform strategy. It is with regrets that I leave the Linux Foundation, but if you haven’t figured out already, Sun is a company I’ve always loved, and being a part of it was an opportunity I simply could not pass up. I think the world of the people at the LF, particularly my former FSG colleagues with whom I worked so closely over the past year and a half: Jim Zemlin, Amanda McPherson, Jeff Licquia, and Dan Kohn. And I still very much believe in the core LF mission, to prevent the fragmentation of the Linux platform. Indeed, I’m remaining in my role as chair of the LSB—and Sun, of course, is a member of the Linux Foundation. Anyway. Watch this space. This is going to be fun!

Jason Matusow of Microsoft wants to know:

That said, the real voice of the community is…well…from those of you I don’t know. I have to tell you that the issues with getting this covenant right are incredibly complex and there are real concerns on all sides. Our design goal is to get language in place that allows individual developers to keep developing.

(This is in response to the recent patent deal between Microsoft and Novell, and the poor reception it’s getting from the free software community.) Unfortunately, he got GrokLaw-ed, and his comment system isn’t taking the heat well. So, here’s my feedback; hopefully, he’s paying attention to views outside his comments. The big problem, if you ask me, is the distinction between “commercial” and “non-commercial” that Matusow (and everyone else I hear from Microsoft) is making. In our world, that distinction is a lot less important than the distinction between “proprietary” and “open”. For us, “commercial” is just another way software can be used, and restrictions on commercial use are like restrictions on use by women, or by people in Illinois, or by people who have ever picked their nose in public. Why are businessmen any less deserving of our software as a class than housewives, or Haitians, or other free software developers? Matusow claims not to be interested in any of this:

We are not interested in providing carte blanche clearance on patents to any commercial activity - that is a separate discussion to be had on a per-instance basis. As you comment, please keep in mind that we are talking about individuals, not .orgs, not .com, not non-profits, not…well, not anyone other than individual non-commercial coders.

Dialogue often means meeting the other person where they’re at, not where you want them to be. They would, presumably, not take us seriously if we insisted on a blanket patent license as a condition for any kind of conversation. Fair enough; but then why should we taken them seriously when they insist on us turning our backs on one of our bedrock principles? But does the conversation have to be either-or? I’m betting that Matusow’s blog post is evidence that it doesn’t. People at his level are not the types to waste time on wild goose chases. And is it all that strange to think there might be value in the conversation? There’s a mighty thin line between “proprietary” and “commercial”, so thin even we get them confused sometimes. Does Microsoft really care all that much about for-profit use and improvement of free and open tech? If so, they’re prominent members of a small and shrinking club. If not, then it seems to me that we have a lot of common ground for discussion.

Jeff Licquia: “Ian has been filling my head with tantalizing visions of replacing my hosted boxes with online apps. I think I m going to give some of these a spin, but I m not convinced yet. It seems to me that the lesson to learn don t put all your eggs in one basket argues equally well either way.”

Well, it’s been over a month since the last entry. So much for posting more often! Today, I’ve updated the blog to WordPress 2.0.3, and installed a new theme. I wasn’t too happy with the old Steam theme, but it was a variable-width theme, and I can’t stand fixed-width themes. (Why buy a better monitor if all the Web pages are forced to 600 pixels?) But with the new and improved theme support in 2.0, there are some nice themes that use your whole browser window. (Posted to all known aggregators, too; I hope Planet doesn’t decide all my posts are new now.) UPDATE: Well, that was fun; the nice-looking theme happens to be completely invalid. Expect theme changes over the next short while. UPDATE: Wow, that’s depressing; the state of valid XHTML in WordPress themes is, uh, underwhelming. So I switched back to the nice theme, and edited it to be valid XHTML 1.0 Transitional and valid CSS. I’ve set up a Bazaar-NG repository for my changes.

Now that the right people have been told, I can make it public: as of January, I’ll be a full-time developer for the Free Standards Group, producers of the LSB. This is, perhaps, one of the most difficult job decisions I’ve had to make. In every other case where I’ve changed jobs so far, I’ve done so only when it becomes clear that the old job isn’t going anywhere: either by going under, getting radically reorganized, treating me poorly, or otherwise being a dead end. None of that is true here. I still believe in what Progeny is doing. The co-workers are superb (yes, even that one), and management has always treated me well, even in difficult circumstances. But sometimes, opportunities are too good to pass up. I think that the next year or two will be pivotal to the future of free standards, and I’ll be in a unique position to influence the direction those standards go. Plus, I’ll be able to work with another group of brilliant and talented people, with the hope that some of that brilliance and talent will rub off. I’m also positive about working primarily from home. So, you can expect more blogging (he says, a month after his last post!), especially about standards in the free software world. I’ve created a new category for that topic, in case you’re interested in following just that conversation.

I’ve seen several requests for a simple set of instructions that test a distribution against the LSB. I wrote some Debian-specific instructions in a mailing list post back in October, and thought they’d do better as more general instructions. Before you start, you have to find out two things about the distribution you want to test:

• How to install the LSB on your distribution. At minimum, your distro should provide something like a “lsb” package. Make sure that’s installed.
• How to install LSB packages on your distribution. RPM-based distros have it easy here, since the procedure is likely to be the same as installing any other package on your system. Debian users (and users of Debian derivatives) need to use alien; I’ve found that you get the best results with alien -ick [package]. Other distributions will have their own ways, possibly involving alien as well.

Go to the LSB download page and start downloading everything under the Runtime Tests for the LSB version and architecture you want to test. Make sure you don’t get the betas unless that’s what you want to test. You will also need the lsb-python package from the Application Battery list. Install all of these packages. Once all of the packages are installed, run the tests:

• /opt/lsb/bin/lsblibchk
• /opt/lsb/bin/lsbcmdchk
• Add /usr/opt/lsb/appbat/bin to your PATH, run gcc -dumpmachine to get your machine triplet, and run /opt/lsb/share/test/qmtest_libstdcpp_[version]/run_tests. Answer the questions as appropriate.
• For the X test suites, install enough of XFree86 or X.org on your system for proper client support, as well as the Xvfb X server. Debian users can install the x-window-system-core and xvfb packages, but see below about problems with Xvfb. After this is done, go to the directory /opt/lsb/test/vsw4 and run the run_vsw4.sh script found there.
• For the main runtime test, make sure the loop driver is loaded. (This is mostly a problem on systems using udev.) After the test package is installed, set passwords for the “vsx0″, “vsx1″, and “vsx2″ users, log in as vsx0 at a system console, and run run_tests. Logging in is required; su or sudo won’t work. The default answers to the questions asked are mostly OK, but a few don’t have good defaults. In particular, you’ll have to tell the script the right passwords for the vsx users, and you should make sure the test block device is /home/tet/test_sets/nonexistb. Be prepared to type the root password several times to set up various things the tests need.

Most of the tests are quick, taking less than 15 minutes usually per test. The runtime test takes somewhere in the neighborhood of six hours, and often looks like it has hung. Don’t assume the runtime test has hung until it’s run overnight. If you’re using an emulator, don’t give up on runtime until it’s run for at least 24 hours. The tests create two kinds of files: journal files, and the official runtime report (created by the runtime test). Where you ran the tests, look for files with names starting with “journal” in the current directory, or for paths like results/0001e/journal. The C++ tests create a directory called “qmtest_libstdcpp_[version]”. There’s a handy utility called tjreport in /opt/lsb/bin; run that on the journal to get a quick summary of the results. If you want to post results, use tjreport. The official runtime report (in /home/tet/test_sets/results) has some additional information: a list of FIP (Further Information Provided) results. What to do with failures: First, make sure it’s really a failure of the environment, and not a failure of the tests. The LSB publishes a list of official waivers for test failures; check that your failures aren’t on that list. For failures not on that list, Google is your best resource; most likely, someone else has experienced the same failure, and will have more information about it. If you really can’t figure it out, come over to one of the LSB’s mailing lists and ask around. On Xvfb: The Xvfb versions shipped with most distributions have bugs that can cause problems. Anything running XFree86 will likely not be able to complete the X tests, and anything running X.org may see a number of failures. Because Xvfb is not required by the LSB, you can replace Xvfb with one that doesn’t have these bugs. Recent Debian xvfb packages for etch don’t have these bugs, so Debian and derivatives can use them for testing. (The sarge backport of Xvfb can be installed on vanilla sarge without upgrading any of the other XFree86 packages; missing packages can also be pulled from the sarge backport without affecting the packages that do ship.) Please post questions, problems, criticisms, etc. in the comments. A version of this might end up on the LSB site someday, so any improvements would be appreciated.

A while back, I wrote about a system called Autopackage, which attempted to solve some of the problems with software installation on Linux. I had some praise and a few criticisms of the project, and some of the autopackage people came by and discussed some of them. I still get new comments on that post every so often, mostly of the “if you don’t like autopackage, don’t use it” variety. Autopackage has attracted a lot more criticism over time, and it seems that criticism has driven at least one autopackage person completely batty. Apparently, nearly everything violates their idea of how the world should work: package managers, Python, C++, the standard C library, the ELF executable file format, and the dynamic linker, at least. Others have observed their poor attitude, and have pointed out inaccuracies. The whole incident is frustrating. Autopackage does some things well. Their efforts to solve binary compatibility problems, for example, have resulted in some seriously cool utilities. But they seem to have an inflated opinion of themselves, and it closes their minds to working with others. With me, it was the idea that distributor support could possibly be desireable for users. This seemed to be a totally alien concept to them I do want to emphasize Klik, though (from Erich’s link). It appears to solve many of the same problems, but without insisting that the entire software infrastructure behind Linux adapt to it.

Today, Indiana joined the rest of the country and “sprang forward” to Daylight Saving Time. The technology world may be experiencing a few glitches. Anything that’s aware of both location and time may have the wrong time as of today, including many computers. The easiest fix is to change the timezone to New York time, or to Eastern time instead of “East-Indiana” or some such variant. Surprisingly, Sprint phones don’t seem to be aware of the time change. The update seems to be both late and iffy; my phone still reports the wrong time, while my mother-in-law’s phone has already fixed itself. Debian 3.1 appears to still have the old timezone information, while testing (”etch”) seems to be correct. I wonder if this isn’t something we should update in stable.

Ulrich Drepper slams on the LSB, suggesting that binary compatibility is a red herring and that the LSB is incompetent. I think it best to respond to the substance of the allegations here. To do that, you’ve got to filter out the ad hominem slurs (”…they buy into the advertisement of the people who have monetary benefits from the existence of the specification, they don’t do any research, and they generally don’t understand ABI issues.”), ego (”After they added the 100+ reports I sent and those others sent the test suite is a somewhat good reflection of who a Linux implementation should behave…”), and contradictions (even though the LSB people are incompetent, their experience shows that their goal is unattainable; one would think you need to try with competent people before deciding that something is impossible). So what are you left with?

• Test suites have bugs, even embarassing ones. Are we supposed to be surprised by this? Yes, part of the thread test bug Drepper highlights is pretty stupid. But who can claim to have never written stupid code? Certainly not I, and certainly not Drepper.
• The tests are incomplete. This is both because of incomplete specifications and bugs, which cause discrepancies from the specs. By this logic, software testing is also useless for the same reasons. In the cases where the tests are right, can we not depend on them? “Useful” need not imply “perfection”, as all users of glibc today can testify.
• Waivers are signs of incompatibility. Drepper’s complaint: “The result of all this is that you can have a program which is certified for LSBv3 which doesn’t run on all LSBv3 certified systems, depending on whether the LSB environment worked around the broken test or not.” But software vendors can easily retrieve a complete list of waivers, which allows vendors to anticipate what discrepancies they’re likely to encounter. Vendors may be ignorant of the issues, but that is hardly the LSB’s fault.
• Having separate runtime environments for LSB issues is bad. First of all, Drepper seems to think that people doing separate LSB runtimes (like me) are doing it to work around LSB test problems. In Debian, however, 100% of the bugs I work around with the dynamic linker are bugs in Debian, not bugs in the tests, and only one of those bugs is not a glibc bug. Second, if the separate LSB runtime environment is complete, why should it matter that it’s different from the default, as long as it follows LSB behavior?

As a final point, I would look at Drepper’s recommendations for a replacement of the LSB: source specifications, and identical binaries whenever ABI compatibility is an issue. He doesn’t answer the question of whose binaries those should be, probably because he’s happy with the current de facto answer: the binaries provided by his employer, Red Hat. No doubt he would prefer a world without competition, but should the rest of us? (Seen via Slashdot.)

Joey Hess is happy to see us using debian-installer for the DCC Core, and speculates about whether Progeny will be moving away from Anaconda. First of all, I certainly hope we can make useful contributions to d-i. As a first effort, the long-stalled debian-installer module for picax (started at DebConf 4) is now in good shape, and was what we used to build DCC 3.0 PR1. And I can honestly say that d-i has, so far, exceeded our expectations. On the other hand, there’s no reason why we can’t have more than one installer for Debian. FAI has been around for a long time, after all. Some people like Anaconda’s UI better than d-i’s, and probably will continue to even after d-i goes graphical. As long as people want it, there’s no reason why Anaconda for Debian should die off.

It’s now available, and mostly works. There are two source packages and four binary packages available here and here. One source package builds the dynamic linker itself, as well as the fixed libc. The other fixes a bug in PAM; the pam_unix module returns success instead of the proper error under some circumstances. See Debian bug 323982 for the details. If necessary, the package could be itself patched, but as I’m focused on Debian stable’s LSB compatibility, I’m assuming that there will be resistance to the idea of patching stable in this way. With these packages installed on top, nearly all of Debian’s LSB problems are resolved. Some exceptions may be found in this post.

Jeff Licquia: “I was as surprised as Ian to see Jeremy s response. Why do I not have a Yahoo account? Because I don t trust Yahoo to be as careful with my data as I am. You d think Yahoo would want to convince me otherwise; after all, I frequently dole out advice on things like this to hundreds of potential Yahoo customers. Apparently, there s some advantage to confirming my paranoia, however many people I scare off software-as-a-service using that confirmation as ammunition.” Technorati Tags: softwareasaservice, web20, yahoo